Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

6장. Low Latency를 가능하게 하는 구조

6.1 왜 데이터 구조까지 바뀌어야 했는가

5장에서 LL-HLS의 핵심은 “기다림을 줄이는 것”이었다.

segment를 더 작게 만들고, 데이터를 만드는 중간부터 전달하며, 요청을 기다리는 방식으로 바꾼다.
이 중 가장 중요한 변화는 이것이다.

완성된 파일이 아니라, 생성 중인 데이터를 전달한다

이걸 구현하려고 하면 기존 HLS에서 사용하던 .ts 구조가 맞지 않는다는 문제가 나온다.
즉 단순히 동작을 바꾸는 것이 아니라, 데이터를 담는 방식 자체가 바뀌어야 한다.

6.2 TS는 왜 중간 전송이 어려운가

TS는 방송 송출을 위해 만들어진 포맷이다.
파일이라기보다 “흘러가는 신호”에 가깝다.

구조를 보면 작은 패킷(188 byte)들이 계속 이어지는 형태다.
겉보기에는 잘게 쪼개져 있지만, 이 패킷들은 각각 독립적인 재생 단위가 아니다.

즉 이런 특징을 가진다.

  • 데이터가 연속된 흐름으로 이어져 있음
  • 특정 구간만 잘라서 바로 재생하기 어려움
  • 디코딩 정보가 여러 구간에 걸쳐 존재함

그래서 이런 문제가 생긴다.

“지금 이 부분만 잘라서 바로 재생하자”가 어렵다.

결국 안정적으로 재생하려면 이렇게 된다.

segment 전체가 완성된 뒤에 전송해야 한다

중간에 보내면 재생이 깨지거나 디코딩이 실패할 수 있기 때문이다.

6.3 fMP4는 왜 가능한가

이 문제를 해결하기 위해 등장한 것이 fMP4 구조다.

핵심은 단순하다.

데이터를 “의미 있는 조각” 단위로 나눈다

fMP4는 다음과 같은 구조를 가진다.

init.mp4 (초기 정보)

moof + mdat  ← 1번째 조각
moof + mdat  ← 2번째 조각
moof + mdat  ← 3번째 조각
...

여기서 중요한 포인트는 이것이다.

moof + mdat 하나가 “독립적인 재생 가능한 조각”이다

각 조각은

  • 어떤 시간 구간인지 정보가 있고
  • 그 구간의 영상 데이터가 포함되어 있으며
  • 이 조각만으로도 디코딩이 가능하다

즉 앞 데이터를 몰라도 재생이 가능하다.

이 구조 때문에 가능한 변화가 생긴다.

  • 전체 segment를 기다릴 필요 없음
  • 조각 하나가 만들어지면
  • 바로 전송 가능

즉 이렇게 바뀐다.

TS: 전체가 하나의 흐름
fMP4: 완전한 조각들이 이어진 구조

이 차이 때문에 Low Latency가 가능해진다.

“완성 후 전송”에서 “생성 중 전송”으로 전환

6.4 fMP4만으로는 부족했던 이유

여기까지 보면 fMP4로 모든 문제가 해결된 것처럼 보인다.

하지만 실제 서비스에서는 또 다른 문제가 생긴다.

각자 방식대로 쪼개기 시작하면 호환이 깨진다.

  • 어떤 인코더는 0.5초 단위로 자르고
  • 어떤 인코더는 1초 단위로 자르고
  • 플레이어마다 지원 방식이 다르고
  • HLS와 DASH 구조도 서로 다르다

즉 기술적으로는 가능하지만
실제 서비스에서는 혼란이 발생한다.

6.5 CMAF는 무엇을 해결했는가

이 문제를 해결하기 위해 등장한 것이 CMAF다.

중요한 포인트는 이것이다.

CMAF는 새로운 구조가 아니라
fMP4를 어떻게 사용할지 정의한 규칙이다

CMAF는 세 가지를 표준화한다.

첫 번째는 “쪼개는 단위“

데이터를 다음과 같은 계층으로 나눈다.

  • Segment → 플레이어가 인식하는 단위
  • Fragment → 내부 논리 단위
  • Chunk → 실제 전송 단위

그리고 중요한 규칙을 만든다.

각 chunk는 독립적으로 디코딩 가능해야 한다

이 규칙 덕분에 중간부터 받아도 재생이 가능해진다.

두 번째는 “전송 방식”

과거에는 fMP4를 사용해도
segment 전체를 다 만든 뒤 보내는 경우가 많았다.

CMAF는 이렇게 정의한다.

chunk가 만들어지면 즉시 전송해야 한다

이때 사용하는 방식이 HTTP Chunked Transfer다.

즉 데이터가 파일처럼 한 번에 내려오는 것이 아니라
스트림처럼 계속 흘러오게 된다.

세 번째는 “호환성”

과거에는

  • HLS용 fMP4
  • DASH용 fMP4

구조가 달라 서로 호환되지 않았다.

CMAF는 이 구조를 통일한다.

그래서 하나의 fMP4 조각으로

  • HLS에서도 재생 가능하고
  • DASH에서도 재생 가능하다

즉 동일한 데이터를 여러 환경에서 그대로 사용할 수 있다.

6.6 전체 흐름 정리

지금까지의 흐름을 정리하면 이렇다.

HLS는 안정성을 위해 설계되었고
그 구조 때문에 지연이 발생했다.

이를 줄이기 위해 LL-HLS가 등장했고
“만들면서 전달하는 방식”이 필요해졌다.

하지만 TS 구조로는 이를 구현할 수 없었고
그래서 fMP4 구조가 도입되었다.

그리고 실제 서비스에서 사용할 수 있도록
CMAF가 이를 표준화했다.